context: avoid prefixing vars directories #1506
Conversation
This drops the internal prefixing logic for vars directories, thus avoiding the prepended `install_root` path prefix on all entries. It also results in aligning the behaviors of `dnf_context_set_vars_dir()` and `dnf_context_set_repos_dir()`. Existing consumers in the wild are not really expecting this kind of prefixing to happen internally. Additionally, developers seem to naturally assume that the lookalike APIs for repos-dir and vars-dir behave in the same way. Ref: coreos/rpm-ostree#3241 Ref: https://github.com/PackageKit/PackageKit/pull/369/files#r863937752 Closes: rpm-software-management#1503
|
Changing the semantics of an existing API seems like a bit of a trap to me; won't this potentially break rpm-ostree/PackageKit if they update to this version without also changing how they call the API? WDYT about adding a new API |
|
To the best of my understanding, existing software is already written with the expectation that But yes, I'd love some double-checks and feedback from libdnf/microdnf/PackageKit folks before venturing too much into this. |
in scos testing as workaround See: - https://bugzilla.redhat.com/show_bug.cgi?id=2113042 - rpm-software-management/libdnf#1506
|
Hi, sorry but we're decided to rather not merge such a change that could potentially change the existing behavior for API users. |
This drops the internal prefixing logic for vars directories, thus
avoiding the prepended
install_rootpath prefix on all entries.It also results in aligning the behaviors of
dnf_context_set_vars_dir()and
dnf_context_set_repos_dir().Existing consumers in the wild are not really expecting this kind
of prefixing to happen internally. Additionally, developers seem to
naturally assume that the lookalike APIs for repos-dir and vars-dir
behave in the same way.
Ref: coreos/rpm-ostree#3241
Ref: https://github.com/PackageKit/PackageKit/pull/369/files#r863937752
Closes: #1503